1. Field of the Invention
This invention relates to information-sharing systems and, more particularly, to event-driven systems for providing continuous responses to multisource real-time queries.
2. History of the Prior Art
Running a business requires that information be available to persons with many different needs. For example, a wholesale business orders goods from many different manufacturers; warehouses the goods purchased at different places, often in different environments; receives orders arriving at many different times from many different customers situated in many different places; arranges to receive payments in many different ways; ships products to customers using many different shipping channels; and tracks accounts relating to these suppliers and customers. A shipping clerk needs entirely different information relating to a particular item of goods than a warehouse supervisor, a purchasing agent, or a tax accountant even though all of these persons work for the same wholesale business.
The personnel of a business typically satisfy their needs for information by searching for that information in a relational database. A relational database stores historical data in multiple tables in the long term memory of a computer. Personnel typically enter the data from summations into computer displayed forms provided by the database program. The database program stores the data entered in the appropriate tables. Each table includes rows of records with many different fields each holding information defining the record. The different tables in a relational database often have one or more fields which are identical to fields in other tables and provide a link by which data in one table may be related to data in another table.
When an employee of a business desires information to carry out a particular job, the employee directs a query to the database. Such a query causes the software to select information from one or a number of different tables, often to manipulate that information in some manner, and to return the results of the query to the employee, often in some form of report. A query allows an employee to provide very complicated criteria to the database accessing software. The response to a query can thus include result from very sophisticated manipulations of the historical data which has been entered into the database.
Because of this, queries to a typical database may be devised to provide the particular information that each individual employee needs. Because queries may be so personalized, hundreds and often thousands of different individual queries are likely to be submitted continuously to a database in a large business. Each time an employee needs information from a database on which to base a decision, the employee must submit a new query even though the query may be identical to a query previously submitted by that employee. Each individual query is run to completion by the computer executing the database software. As a business grows larger, queries tend to occupy more and more of the time available to the computer running the database. In fact, a large relational database may often become unable to respond effectively to the business queries it receives regarding historical information in the database.
Although many business operations are satisfied by the historical data provided by a typical relational database and are able to cope with slow access speeds, there are any number of processes in a business which only function optimally if those making decisions about the processes are provided immediately with the results of continuously changing events affecting the processes. Manufacturing processes are typical of operations which require real-time monitoring. Manufacturing processes, however, are so important that they are usually handled by computer systems dedicated to the individual processes.
Other important processes have not been so well treated by prior art support systems. Many other business processes benefit greatly if business decisions can be made in real time in response to real-time events. For example, if a business furnishes trucks to pick up the goods it purchases, a last minute change in the number of items which have been purchased requiring a larger truck will require the additional expense of an extra trip if not discovered before a first truck has been dispatched. The availability of real-time information can determine whether many businesses are profitable or not.
A typical relational database is not suited to produce up-to-date results from continually changing data. A database usually contains only historical data. Consequently, the entire design of databases has been organized to optimize the processes by which the many tables of large databases are searched in response to individual queries devised by a large variety of employees to provide this historical data to users.
Although relational databases have some functions which allow responses to real-time events, these functions are so limited in nature that they do not provide a useful solution where real-time decisions are necessary. For example, some databases provide what are referred to as triggers. A trigger can be coded into the software to run a process in response to some change which occurs to some data in the database. Such a process must be precoded into the software and is not subject to immediate change to suit changing circumstances. Moreover, trigger processes cannot be used on a large scale to respond to real-time events. A trigger process runs serially like other processes on the computer. Consequently, if constantly occurring trigger processes were to be used for a variety of purposes, the entire database would simply slow to a halt.
Another type of system for providing information is referred to as an event service. A method used by event systems to respond to real-time events involves what are called filters or event processing. Filters are used to look for the occurrence of events which meet particular criteria. However, filters used by prior art event services are able to respond only to criteria which exist in the event itself and cannot provide more sophisticated functions.
For example, if an event indicates that a package is arriving from a manufacturer containing an amount of some goods, only the data actually in the event can be utilized by the filter. The manufacturer, the goods, the amount of goods, and the time of arrival can be provided to persons interested in the results of the filter, but no other information already in any database can be associated with the event data by the filter. None of the sophisticated processes available to a database such as relating values in different tables which pertain to the package can be carried out. No historical data related to the manufacturer, the goods, or the amounts of the goods can be determined.
Thus, a filter could not be used to determine whether an additional truck was necessary in the previously-mentioned case because historical data could not be combined with event data by an event service.
There are at present no systems for providing immediate results to multi-dimensional sophisticated queries for events occurring in real time. It is desirable to provide such systems.